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O (57) Abstract: The invention relates to a method for translating programmes into a system consisting of at least one first processor 
A and a re-configurable unit According to the method, parts of the code that are suitable for the re-confignrable unit are determined 
and extracted and the remaining code is extracted in this manna: for processing by the first processor 
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(57) Zusammenfossung: Die Erfindung betrifft ein Verfahren zur Cbersetzung von Programmen auf ein System bestehend aus 
wenigstens einem ersten Prozessor ond einer rekonflgurierbaren Einheit. Hierbei ist vorgesehen, dass die Ctodeteile, die fUr die 
rekonfigurieibare Einheit geeignet sind, bestimmt und extrahiert werden und der veibleibende Code zur Abarbeitung duich den 
ersten Prozessor derart extrahiert wild. 
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Titel: Verfahren zur Bearbeitung von Daten 

Beschreibung 

Die vorliegende Er£indung befalSt sich mit Datenverarbeitung. 
Insbesondere befafit sich die vorliegende Erfindung mit her- 
k6nimlichen, d«h. konventionellen und rekonf igurierbaren Pro- 
zessorarchitekturen sowie mit Verfahren hierfCir, die eine 
Ubersetzung einer klassischen Hochsprache (PROGRAMM) wie 
Pascal, C, C+-i-, Java, etc. ermdglichen, insbesondere au£ eine 
rekonfigurierbare Architektur, Insbesondere* befafit sich die 
vorliegende Erfindung mit der Integration und/oder engen Kopp- 
lung von rekonf igurierbaren Prozessoren mit Standardprozesso- 
ren, dem Datenaustausch luid der Synchronisation der Datenver- 
arbeitung. 

Unter einer konventionellen Prozessorarchitektur (PR02BSS0R) 
werden vorliegend beispielsweise sequentielle Prozessoren mit 
einer von-Neumann- oder Harvardarchitektur verstandea, wie 
z.B. Kontroller, CISC-, RISC-> VLIW-, DSP-, U.S. Prozessoren 
verstanden. 



BESTATIGUNGSKOPIE 
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Unter einer rekonf igurierbaren Zielarchitektur werden vorlie- 
gend Bausteine (VPU) mit wiederholt und insbesondere zur Lauf- 
zeit insbesondere imterbrechungsfrei konf igurierbarer Funktion 
und/od6r Vemetzung verstanden, insbesondere integrierte Bau- 
steine mit einer Mehrzahl von ein- oder mehrdimensional ange- 
ordneten arithmetischen und/oder logischen und/oder analogfen 
und/ Oder speichemden insbesondere evtl. auch grobgranularen 
Baugruppen (PAE) , die direkt oder durch ein Bussystem mitein- 
ander verbunden sind. 



Zur Gattimg dieser Bausteine zShlen insbesondere systolische 
Arrays, neuronale Netze, Mehrprozessor Systeme, Prozessoren 
mit mehreren Rechenwerken und/oder logischen Zellen, Vemet- 
z\ings- \md Netzwerkbausteine wie 2.B. Crossbar- Schalter, eben- 
so wie bekannte Bausteine der Gattung FPGA, DPGA, XPUTER, 
etc., Hingewiesen wird insbesondere in diesem Zusammenhang auf 
die foigenden Schutzrechte desselben Anmelders: P 44 16 881.0- 
53, DE 197 81 412.3, DE 197 81 483.2, DE 196 54 846.2-53, 
BE 196 54 593.5-53, DE 197 04 044.6-53, DE 198.80 129.7, 
DE 198 61 088.2-53, DE 199 80 312.9, PCT/DE 00/01869, DE 100 
36 627.9-33, DE 100 28 397.7, DE 101 10 530.4, DE 101 11 
014.6, PCT/EP 00/10516, EP 01 102 674.7, DE 196 51 075.9-53, 
DE-a96 54 846.2-53, DE 196 54 593.5-53, DE 197 04 728.9, 
DE 197 07 872.2, DE 101 39 170.6, DE 199 26 538.0, 
DE .101 42 904.5, DE 101 10 530.4. Diese sind hiermit zu Offen- 
barungszwecken vollumfSnglich eingegliedert . 

Das System kann insbesondere als (Standard) -Prozessor oder 
Baugruppe ausgestaltet sein und/oder in einem Halbleiter tSy- 
stem on Chip SoC) integriert sein. 

Rekonfigurierbare Bausteine (VPUs) unterschiedlicher Gattungen 
(wie z.B. PACT XPP-Technologie , Morphics, Morphosys, Chamele- 
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on) Bind zu bestehenden technischen Dmgebungen und Program- 
mierverfahren weitgehend inkompatibel . 



Programme far diese Bausteine sind typisch inkompatibel zu be- 
reits bestehenden Programmen von CPUs. Dadurch wird ein erheb- 
licher Bntwicklungsaufwand zur Prograramierung erforderlich, 
z.B. besonders ffir Bausteine der Gattungen Morphics, Morpho- 
sys. Chameleon integriert bereits einen Standardprozessor 
(ARC) auf mehr oder minder rekonf igurierbaren Bausteinen. Da- 
durch stehen AnsStze fdr Tools zur Programmierung zur Verfii- 
gung. Allerdings ist nicht jede technische Uttigebung fir den 
Einsatz von ARC-Prozeesoren geeignet, insbesondere liegen be- 
stehende Programme, Codebibliotheken etc. oftmals fttr beliebi- 
ge unbestimrate andere CPUs vor. 

Es hat sich in internen Versuchen gezeigt, daS es bestimrate 
Verfahren und ProgrammablSufe gibt, die sich besser mit einer 
rekonfigurierbare Architektur abarbeiten lassen als mit einer 
konventionellen Prozessorarchitektur. Umgekehrt gibt es auch 
solche Verfahren und Programmablauf e, die besser mit einer 
konventionellen Prozessorarchitektur ausgefOhrt werden k6nnen.- 
Es ist dafilr wunschenswert, um eine jeweilige Optimierung zu 
ermSglichen, eine Ablaufteilung vorzusehen. 

Bekannte Ubersetzungsverfahren fur rekonfigurierbare Architek- 
turen unterstiitzen keine Weitergabe von Codes an beliebige 
Standard- Compiler zur Generierung von Objektcodes fiir einen 
beliebigen PROZESSOR. .Gew6hnlicherweise ist der PROZESSOR fest 
innerhalb des Compilers jdefinier.t. 

Weiterhin existieren keine Scheduling-Mechanismen zur Rekonfi- 

guration der einzelnen generierten Konfigurationen fir VPUs. 

Insbesondere fehlen Scheduling-Mechanismen far die Konfigura- 
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tion unabhSngiger extrahierter Teile gleichwohl wie filr ein- 
zelne Partitionen extrahierter Teile. Entsprechende Dberset- 
ziingsverfahren nach dem Stand der Technik sind beispielsweise 
def iniert durch die Dissertation ^tteersetzungsmethoden fflr 
stnikturprogrammierbare Rechner, Dr. Markus Weinhardt, 1997*. 

Zur Partitionierung von Array-CODB sind mehrere Verf ahren nach 
dem Stand der Technik bekannt, z. B, Joao M. P. Cardoso, Com- 
pilation of Java'* Algorithms onto Reconf igurable Computing Sy- 
stems with E3cploitation of Operation-Level Parallelism*/ Ph. 
D. Thesis Universidade Tficnica de Lisboa (UTL) , 2000. 

Diese Verf ahren sind jedoch in keine kompletten Compilersyste- 
me eingebettet. Weiterhin setzen die Verf ahren die vollst&ndi- 
ge Steuerung der Rekonf iguration durch einen Hostprozessor 
voraus, was einen erheblichen Aufwand bedeutet. Die Partition 
nierungsstrategien sind fiir FPGA-basierende Systeme ausgelegt 
\md entsprechen daher keinem echten Prozessormodell. 

Die Aufgabe dieser Erfind\ing besteht darin, Neues fixr die ge- 
werbliche Anwendung bereitzustellen. 

Die Losung dieser Aufgabe wird in unabhSngiger Form bean- 
sprucht. Bevorzugte Ausfuhrungen finden sich in den Uhteran- 
spriichen. 

Bin rekonfigurierbarer Prozessor tVPU) wird somit in eine 

technische Umgebung eindesigned, die. einen Standardprozessor 

(CPU) besitzt, wie beispielsweise einen DSP, RISC, CISC- 

Prozessor oder (Mikro) -Kontroller aufweist-. Das Design kann 

erf indungsgemSS derart erfolgen, dass eine einfache und lei- 

stungsfShige Anbindung besteht. Bin sich ergebender Aspekt ist 

die einfache Programmierbarkeit des entstehenden Systems. Die 
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Weiterverwendung bestehender Programme der CPU sowie die Code- 
korapatibilitat \md die einfache Integration der VPU in die be- 
stehenden Programme finden Berucksichtigung. 

Eine VPU (oder ohne jeweils besonders erwahnt zu werden, meh- 
rere VPUs) wird derart mit einer bevorzugten CPU (oder ohne 
jeweils besonders erwahnt zu werden, mehreren CPUs) gekoppelt, 
dass sie die Stelle und Punktion eines Coprozessors (bzw. meh- 
rerer wahlweise ansprechbarer Coprozessoren) einniramt. Die 
Punktion ermSglicht die einfache Einbindung in bestehende Pro- 
grammcodes entsprechend den bereits existierenden Methoden zum 
Umgamg mit Coprozessoren nach dem Stand der Technik. 

Der erfindungsgemSfie Datenaustausch zwischen CPU und VPU kann 
mittels Speicherkopplung und/oder lO-Kopplung erfolgen. CPU 
und VPU kdnnen samtliche Ressourcen teilen, in besonderen Aus- 
gestaltungen ist es auch moglich, dass CPU und VPU nur eihen 
Teil der Ressourcen gemeinsam verwenden und andere Ressourcen 
jeweils explizit und/oder exclusive fflr eine CPU oder VPU zur 
VerfCigung stehen. 

Um einen Datenaustausch durchzufiihren, konnen DatensStze 
und/oder Konf igurationen in jeweils besonders dafdr vorgesehen 
Speicherbereiche kopiert bzw. geschrieben/gelesen werden 
und/oder entsprechende Basisadressen gesetzt werden, dass die- 
se auf die jeweiligen Datenbereiche zaigen. 

Zur Steuerung des Coprozessors wird bevorzugt ein Datensatz 
vorgesehen, der beispielsweise die Grundeinstellungen einer 
VPU beeinhaltet, wie beispielsweise bestimmte Basisadressen. 
Desweiteren kdnnen Statusvariablen zur Ansteuerung und Funkti- 
o^ssteuerung einer VPU durch* eine CPU sowie f flr Rilckmeldungen 
einer VPU an eine CPU vorgesehen sein. Der Datensatz kann toer 
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einen getneinsamen Speicher (RAM) und/oder uber einen gemeinsa- 
men peripheren Adressraum (10) ausgetauscht werden* 

Zur Synchronisation der CPU und VPU k6nnen einseitig oder ge- 
genseitig wirkende Interruptverfahren (die z.B. durch Signal- 
transfer aber insbesondere dedizierte bzw. hierfur ausgebilde- 
te Interruptleitungen und/oder InterrupteingSnge realisiert 
sind) vorgesehen sein und/oder die Synchronisation erfolgt 
mittels PollingverfcQiren. Weiterhin konnen Interrupts zur Syn- 
chonisation von Daten- und/oder DMA- Transfers verwendet wer- 
den. 

In einer besonders zu bevorzugenden Ausgestaltung wird eine 
VPU durch eine CPU gestartet und arbeitet danach bevorzugt un- 
abhangig die i^plikation ab. 

Besonders leistvmgsfahig ist ein bevorzugter Aufbau, bei wel- 
chen die vervrendete VPU eigene Mechanismen zum Laden und Kon- 
trollieren von Konf igurationen vorsieht. Zur Gattung dieser 
VPUs gehdren beispielsweise PACT XPP und Chameleon. Die erf in- 
dungsgemaSen Schaltxmgen ermoglichen ein Verfahren zum Betrieb 
derart, dass die Konf igurationen der VPU zusammen mit dem aus- 
zufOhrenden Programm der CPU in einen Speicher geladen werden. 
Die CPU kaxm wShrend der Ausfflhmng des Programmes die VPU auf 
die Speicherstellen verweisen (z.B. durch Angabe der Adressen 
Oder Pointer) , die die jeweils auszufCihrenden Konf igurationen 
beinhalten. Die VPU kann daraufhin die Konf igurationen selb- 
standig und ohne weitere EinfluSnahme durch die CPU laden. Die 
Ausfiihrung startet sofort oder ggf . durch eine. zusatzliche In- 
formation (z.B. Interrupt und/oder Start Befehl) durch die . 
CPU. 
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In einer besonders bevorzugten Erweitening kann die VPU selb- 
stSndig innerhalb eines Speichers Daten lesen \md schreiben. 

In einer besonders bevorzugten Brweiterung kann die VPU eben- 
falls selbstandig neue Konf igurationen aus dem Speicher laden 
und sich bei Bedarf neu konfigurieren, ohne dass es eines wei- 
teren Einflusses durch die CPU bedarf.. 

Diese Ausgestaltungen errooglichen einen weitestgehend von CPUs 
unabhingigen Betrieb von VPUs. Lediglich ein Synchronisations- 
austausch zwischen CPU xind VPU, der bevorzugt bidirektional 
stattfinden kann, sollte zusitzlich vorgesehen werden, urn die 
Datenverarbeitungen und/oder KonfigurationsausfOhrungen auf- 
einander abzustimmen. 

Es wurde weiter erkannt, dafi Verfahren zur Datenverarbeitung 
bevorzugt so ausgelegt werden kdnnen und/oder sollen, daZ je* 
weils fflr die rekonf igurierbare Zielarchitektur (VPU) beson- 
ders geeignete Teile (VPU-CODE) des zu Clbersetzenden Program- 
mes identif iziert und extrahiert werden, urn eine besonders e£- 
fiziente Datenverarbeitung zu erm5glichen. Diese Teile sind 
entsprechend zu partitionieren und die Kon£iguration der ein.- 
zelnen Partitionen ist in ihrer zeitlichen Reihenfolge zu 
steuem. 

Di.e verbleibenden Teile des Programmes kSnnen auf eine konven- 
tionelle Prozessorarchitektur (PROZESSOR) <ibersetzt werden. 
Dies geschieht bevorzugt dergestalt> daS diese Teile als Hoch- 
sprachencode in einer Standard-Hochsprache (z. B. ANSI C) der- 
art ausgegeben werden, daS ein gewohnlicher (ggf . bereits exi- 
stierender) Hochsprachencompiler diese ohne weiteres verarbei- 
ten kann. 
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Weiterhin sei angemerkt, daS die Verfahren auch auf Gruppen 
von mehreren Bausteinen angewendet werden k&nnen. 



Insbesondere kann eine Art "Double-Buffering" zur besonders 
einfachen und zugleich schnellen Rekonf iguration angewendet 
werden, in welchem eine Mehrzahl von VPUs vorgesehen sind, wo- 
bei ein Teil der VPUs zu einer Zeit rekonf iguriert werden 
kann, zu welcher ein anderer Teil rechnet tind mdglicherweise 
ein Weiterer etwa inaktiv sein kann. Die Daten-, Trigger-, 
Statusverbindungen etc. werden zwischen der Mehrzahl von VPUs 
geeignet ausgetauscht xind ggf . durch adressierte Busse 
und/oder Multiplexer/Demultiplexer entsprechend der aktuell 
aktiven und/oder zu rekonf igurierenden VPUs verschaltet. 

Ein Vorteil dieses Verfahrens liegt darin, daS bestehender 
Code, der fQr einen beliebigf3n PROZESSOR geschrieben wurde, 
unter Einbeziehung einer VPU weiterverwendet werden kann und 
keine oder nur vergleichsweise geringe Modif ikationen durchge* 
fiihrt werden mflssen. Die Modif ikationen kdnnen zudem schritt- 
weise erf olgen, wobei nach und nach immer mehr Code von dem 
PROZESSOR auf die VPU iibertragen werden kann. Da& Projektrisi- 
ko sinkt und die Uberschatibarkeit steigt wesentlich an. £s 
wird darauf hingewiesen, daS einer derartigen sukzessive Ober- 
tragung von itraner mehr Aufgaben auf die VPU, d.h. auf das in- 
tegrale multidimensionale partiell rekonf igurierbaren insbe- 
sondere grobgranulare Feld an Eletnenten, eine besondere Bedeu- 
tung fir sich hat und fiir sich als erfinderisch angesehen wird 
aufgrund seiner gravierenden Vorteile bei der Systemportie- 
rung. 

Weiterhin kann der Programmierer in seiner gewohnten Entwick- 

lungsumgebung arbeiten und muS sich nicht auf eine neue, mog- 

licherweise fremde Entwicklungsumgebung einstellen. 
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Bin erster wesentlicher Aspekt der vorliegenden Erf indung ist 
darin zu sehen, dafi ein PROZESSOR derart mit einer oder mehre-. 
ren VPU(s) verbunden wird, daS ein effizienter Informations- 
austausch, insbesondere in Form von Daten- iind Status informa- 
tion mdglich ist. 

Der Anordnung eines herkSmmlichen Prozessors \ind eines rekon- 
figurierbaren Prozessors, dergestalt, daS ein Austausch von 
Daten- und/oder Status information zwischen denselben wahrend 
der Abarbeitung eines oder mehrerer Programme moglich ist 
und/oder ohne daS insbesondere die Datenverarbeitung auf dem 
rekonf igurierbaren Prozessor und/oder dem herkommlichen Pro- 
zessor signifikant unterbrochen werden mu&, sowie der Ausbil- 
dung eines derart igen Systems, wird gleichfails fUr sich Be- 
deutxing zugemessen. 

Es k6nnen zunachst beispielsweise eines oder alle der folgen- 
den Verbindungsverfahren \ind/oder -mittel verwendet werden: 

a) Shared-Memory 

b) Netzwerk (beispielsweise Bussysteme wie z.B. PCI-Bus, Se- 
rielle Busse wie z*B. Ethernet) 

c) Kopplung an einen intemen Registersatz oder mehrere* in- 
teren RegistersStze 

d) andere Speichermedien (Festplatte, Flash-ROM, etc.) 

Prinzipiell kann auch die VPU und/oder CPU selbstandig ohne 

Zuhilfenahme eines DMAs auf den Speicher zugreifen. Der ge- 

meinsame Speicher kann insbesondere auch als Dualport- oder 

Multiportspeicher ausgestaltet sein. Dem System konnen weitere 

Baugruppen zugeordnet werden, insbesondere konnen rekonfigu- 

rierbare FPGAs eingesetzt werden, urn eine f eingranulare Verar- 

beitung von einzelner Signale oder Datenbits zu ermoglichen 
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imd/oder flexible adaptierbare Interface (z.B. diverse seriel- 
le Schnittstellen (V24, USB, etc.), diverse parallele Schnitt- 
stellen, Pestplattenschhittstellen, Ethernet, Telekommunikati- 
onsschnittstellen (a/b, TO, ISDN, DSL, etc)) aufbauen zu kSn- 
nen, 

Der Aufbau einer VPU ist beispielsweise bekannt aus den o. g. 
zitierten Anmeldungen. Versuche zu altemativen Bausteindefi- 
nitionen sind beispielsweise unter dem Namen Chameleon gefOhrt 
worden. VPUs lassen sich auf xmterschiedliche Weise in ein Sy- 
stem integrieren. Ein AnschliiE an einen Hostprozessor ist bei* 
spielsweise mdglich. Je nach Verfahren kann der Hostprozessor 
die Konfigurationskontrolle (HOSTRECONF) mit ilbemehmen (z. B. 
Chameleon) oder, z. B., eine dedizierte Einheit (CT) zur 
Steuerung der (Re)Konf iguration bestehen. 

Entsprechend generiert der Ubersetzer gentas dem beschriebenen 
Verfahren die Steuer information fClr die Rekonfiguration f<ir 
eiiie CT und/oder einen HOSTRECONF. 

Es kann nun das Ubersetzungsprinzip derart ausgestaltet sein, 
daS aus einem PROGRAMM mittels eines PRAPROZESSORS die Teile 
extrahiert werden, die sich auf die jeweils bestimmte (n) 
VPU{s) effizient und/oder sinnvoll abbilden lassen. Diese Tei- 
le werden in ein filr VPUs geeignetes Format transf ormiert 
(NML) und dann weiter in einen Objektgode (ibersetzt. 

Der verbleibenden Code und/oder der* extrahierte Code wird er- 

fahrimgsgemas an oder bezQglich der Stelle der durch die Ex- 

traktion fehlenden Code-Teile urn einen Interface-Code erwei- 

tert, der entsprechend der Architektur des Zielsys terns die 

Kotranunikation zwischen PR02BSS0R{en) und yPU(s) steuert. Der 

verbleibende und ggf . erweiterte Code kann bevorzugt 

10 
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trahiert werden sollen. Beispielsweise kann dies folgenderma- 
fien erfolgen: 



Code 

# START_EXTRACTION 

Zu extrahierender Code 

# END_EXTRACTION 

Code 

„l I START_EXTRACTION* kennzeichnet den Beginn eines zu extra- 
hierenden Codes. 

„// BND_EXTRACTION* kennzeichnet das Ende eines zu. extrahie- 
renden Code. 

In einem solchen Pall ist die Einheit zur Urasetzung des Pro- 
gramms in Konfigurationscodes dazu ausgebildet, die Hints be- 
ziehungsweise Umsetzungsvorgaben zu erkennen. 

Es ist auch moglich, dafi zur Extraktion durch Auf ruf von NML- 
Routinen Telle des PROGRAMMES direkt in NML itnplementiert wer- 
den und iA die NML-rRoutinen durch Aufrufe (calls) gesprungen 
wird- Beispielsweise erfolgt dies derart: 

a) NML- Code 

procedure EXAMPLE 
begin 

end 
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b) PROGRAMM Code 
Code 

call EXAMPLE // Aufruf des NML-Codes 

Code 

In diesem Fall ist die Einheit zur Umsetzung dazu ausgebildet, 
NML-Programmteile, das heifit Prograiranteile zur Ausfuhrung in 
\ind/oder auf einem rekonf igurierbaren Array in ein grdSeres 
Programm einzubinden. 

Es ist weiter alternativ xmd/oder zusatzlich eine Extraktion 
aus einer objektorientierten Klasse mdglich. Fdr eine VPU ge- 
eignete Makros werden als Klasse in der Klassenhierarchie ei- 
ner objektorientierten Programmiersprache definiert. Die Ma- 
kros kftmlen dabei: durch Annotation derart gekennzeichnet sein, 
dafi sie als fflr eine VPU bestimmte Codes erkannt xind entspre- 
chend - auch in hdheren Hierarchien der Sprache - weiterverar- 
beitet werden. 

Innerhalb eines Makros ist bevorzugt eine bestinunte Vemetzung 
und/oder* Abbildiing durch das Makro vorgegeben, die sodann die 
Abbildung des Makros auf die VPU bestimmt. 

Durch die Instant iierung und Verkettung der Klasse entsteht 
eine Impleraentierung der Funktion, bestehend aus mehreren Ma- 
kros auf der VPU. Mit anderen Worten definiert die Instantiie- 
rung und Verkettung der Makros die Abbildxing und Vemetzung 
der einzelnen Operationen aller Makros auf der VPU und/oder 
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ggf . die Vernetzung und/oder den Datenaustausch zwischen VPU 
irnd CPU. 



Die Interfacecodes werden bei der Instantiierung hinzugefugt. 
Die Verkettung beschreibt das detaillierte Mapping der Klasse 
auf die VPU. 

Eine Klasse kann beispielsweise auch als ein Aufruf einer oder 
mehrerer NML-Routinen gebildet werden. 

a) Klassen-Code 

class EXAMPLE 
begin 

• • • 
end 

• • • 

b) PROGRAMM Code 

• • • 
Code 

EXAMPLE varO // Instantiierung der Klasse 

Code 

Es ist weiter auch eine Extraktion durch Analyse'^ mSglich. 
Durch an die jeweilige VPU angepaSte Analysemethoden werden 
Teile innerhalb des PROGRAMMES erkannt, die effizient und/oder 
sinnvoll auf die VPU abbildbar sind. 
Diese Teile werden aus dem PROGRAMM extrahiert. 
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Eine beispielsweise fxir viele VPUs geeignete Analysemethode 
ist der Aufbau von Datenflufi- und/oder Kontrollf luSgraphen aus 
dem PROGRAMM. Diese Graphen konnen hinsichtlich ihrer m6gli- 
Chen Partitionierung und/oder Abbildung auf die Ziel-VPU auto- 
mat isch untersucht werden. In diesem Fall werden die Teile der 
generierten Graphen bzw. die entsprechenden PROGRAMMTEILE, ex- 
trahiert, die sich hinreichend gut partitionieren und/oder ab- 
bilden lassen. Hierzu kaiin eine Partitionierbarkeits- und/oder 
Abbildbarkeitsanalyse erfolgen, die die jeweilige Eigenschaft 
bewertet Entsprechend dieser Bewertung erfolgt dcum die Parti - 
•tionierung und Extraktion der Prograramteile auf die VPU, sowie 
das Einfilhren der vorgesehenen Interfaces- . 

Ss soil ausdrficklich auf die in der Patentanmeldung DE 101 39 
170.6 beschriebenen Analysemethoden verwiesen werden, die bei- 
spielsweise zur Anwendung kommen kSnnen. Die vorerwShnte An- 
meldung ist zu Of fenlegungszweckung vollumfanglich eingeglie- 
dert. 

Eine mdgliche Analysemethode ist auch durch Erkennung bestiiran- 
ter Datentypen gegeben. 

Unterschiedliche Datentypen eignen sich mehr oder weniger gut 
fttr die Bearbeitung auf einer VPU. Beispielsweise ist eine 
komplexe Pointer-Arithmetik, bzw. eine pointerbasierende Da- 
tenadressierung (pointer) schwer auf eine VPU abbiidbar, wSh- 
rend sich Arrays (array) sehr gut abbilden lassen.. 

Erfindungsgemas kSnnen daher weitgehend automat isch oder manu- 
ell die jeweils geeigneteh Datentypen und zumindest wesentli- 
che Teile von deren Datenverarbeitung auf eine VPU dbertragen 
und entsprechend extrahiert werden. Die Extraktion erfolgt da- 
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mit im Ansprechen auf das Auftreten bestimmter Datentypen 
und/oder Datenoperationen, 



Es soli erwahnt werden, daS zusatzliche, den Datentypen zuge- 
ordnete Parameter weitere Hinwelse zur Bestimmung der Ausfilhr- 
barkeit und/oder Ausfflhrungsperformance auf einer VPU geben 
kdnnen und daher ina£gebllch zur Extraktion mitverwendet werden 
k&nnen. Beispielsweise spielt die Gr6Se von zu berechnenden 
Arrays eine wesentliche Rolle. Es lohnt sich zumeist nicht, 
kleine Arrays auf einer VPU zu berechnen, da hier der Synchro- 
nisations- und Datenaustauschaufwand zwischen CPU und VPU zu 
hoch sein kann. EinschrSnkend ist aber dabei wiederum zu er- 
w&hnen, dafi kleine Arrays, die innerhalb einer Schleife beson- 
ders hSuf ig verrechnet werden, sich dennoch sehr gut fHx VPUs 
eignen, insofem die Schleife weitestgehend komplett auf der 
VPU berechnet wird. GroBe Arrays k6nnen dagegen zumeist ohne 
weiteres auf einer VPU besonders performant berechnet werden. 

Weiterhin soil erwShnt werden, dafi besondere Datentypen durch 
einen besonders angepaSten Compiler Oder ggf . durch einen An- 
wender (z. B. mittels TYPE in Pascal) erstellt werden k6nnen, 
die sich besonders fxir VPUs eignen und deren Datenverarbeitiing 
dann auf einer VPU ausgefQhrt wird. 
Beispielsweise konnen folgende Datentypen bestehen: 
TYPE streaml of Byte [] ; 
TYPE strearo2 of Byte t0..255; 

Stream def iniert einen Datenstrom (stream)* von in der Kegel 
groSer,. ggf. nicht vorbekannter vmd/oder unendlicher Lange. • 
Streaml hatte hier eine nicht vorbekannte Lcinge. Beispielswei- 
se konnte ein mit diesem Datentyp programmierter FIR-Filter 
(Oder z. B. eine FPT oder DOT) automatisch - und ggf ausge- 

walzt - auf eine VPU abgebildet werden. Die Rekonf iguration 
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erfolgt dann typisch und bevorzugt iin Ansprechen auf andere 
Mechanlsmen als den Datenstromverlauf , z.b. durch Zkhlev, Ver- 
gleicher, CT-gesteuert und/oder durch Time-Out. Soil hierbei 
etwa eine Wave- oder andere Rekonfiguration ausgeldst warden, 
so kann diese uber eine durch vorgenannte Methoden veranlaSte 
Kennzelchnung eines Datenpaketes, insbesondere Datenbytes, als 
ein letztes zu sein erfolgen urn nach uiid/oder mit dem Durch- 
lauf dieses als letzes Datenpaket gekennzeichneten Datenpake- 
tes die Rekonfiguration auszul&sen. 

:stream2 definiert einen Datenstrom der Lange von hier 256 
Byte, der wie streaml behandelt werden kann, jedoch die Eigen- 
schaft au£weist, nach 256 Byte zu enden und damit nach Beendi* 
gung mdglicherweise eine Rekonfiguration im Sinne der vorab 
zitierten Patente selbigen Anmelders ausl6sen kann* Insbeson- 
dere kann eine Wave-Rekonf iguration (z. B. nach DE 197 04 
728.9, DE 199 26 538.0, DE 102 06 857.7, DE 100 28 397.7) mit 
dem Eintreffen des letzten Daten-Bytes ausgelost werden xmd 
mit der Verarbeitung dieses letzten Daten-Bytes die jeweilige, 
das Byte verarbeitende PAE rekonf iguriert werden. 

Eine f"Qr die implementierte VPU geeignete Obersetzung des ex- 
trahierten Codes nach NML karui bevorzugt durchgefuhrt werden - 

Fur datenfluiSorientierte VPUs kann beispielsweise autpmatisch 
ein DatenfluS- und/oder Kontrollf lufigraph aufgebaut werden. 
Die Graphen werden dann in NML-Code xU>ersetzt* 

Entsprechende Code-Teile wie z. B. Schleifen kSnnen mittels 

einer Datenbank (Lookup) Abersetzt werden oder gewdhnliche 

Transformationen kdnnen durchgefiihrt werden. Fflr Codetelle 

kdnnen auch McUcros vorgesehen sein, die dann gemaS den in vor- 

genannten Anmeldungen offenbarten IKR weiterverwendet werden. 
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Ebenfalls kann die Modularisierung nach PACT13, Fig. 28 \inter- 
stutzt werden. 

Gegebenenfalls kann bereits das Abbilden au£ die VPU bzw. des- 
sen Vorbereitung erfolgen, beispielsweise tnittels der Durch* 
fuhrung des Plazierens der ben&tigten Ressourcen iind des Rou- 
tens der Verbindungen (Place and Route) . Dies kann zum Bei- 
spiel nach per se bekannten Regeln des Plazierens und Routens 
geschehen. 

Es ist auch mdglich, mittels einer automatischen Analysemetho- 
de den extrahierten Code und/oder den flbersetzten NML-Code auf 
seine Verarbeitungseff izienz bin zu analysieren. Dabei ist die 
Analysemethode bevorzugt so gewahlt, daS der Interface -Code 
und die daraus entstehenden Performanceeinf Ifisse an geeigneter 
Stelle mit in die Analyse ein£liefien. Geeignete Analyseverfah* 
ren sind insbesondere in den vorgenannten Anmeldungen der vor- 
liegenden Anmelderin beschrieben. 

Gegebenenfalls wird die Analyse durch eine komplette dberset- 
zung und Inclement ierung auf dem Hardware -System durchgef ilhrt > 
iridem das PROGRAMM ausgefOhrt \ind mit geeigneten Methoden, wie 
sie beispielsweise nach dem Stand der Technik bekannt sind, 
vermessen wird. 

Es ist weiter moglich, daS basierend auf den durchgefihrten 
Analysen, verschiedene durch die Extraktion fur eine VPU ge- 
wahlte Teile als ungeeignet identif iziert werden konnen. Umge- 
kehrt kann die Analyse ergeben, da£ bestimmte, fUr einen PRO- 
ZESSOR extrahierte Teile zur Ausfiihrung auf einer VPU geeignet 
wSren. 

17 



wo 02/103532 



PCT/EP02/06865 



Eine optionale Schleife, die nach der Analyse basierend auf 
geeigneten Entscheidxingskriterien zuriick in den Extraktions- 
teil ffihrt, um diesen mit entsprechend der Analyse angepaSten 
Extraktionsvorgaben erneut auszufuhren, ermoglicht die Opti- 
mierung des IJbersetzxingsergebnisses. Man hat somit eine Itera- 
tion. Dieses Vorgehen ist bevorzugt . 

Eine Schleife kann an mehreren unterschiedlichen Stellen in 
den Compilerlauf eingebracht sein. 

Der erhaltene NML-Code ist bei Bedarf entsprechend den Eigeh- 
schaften der verwendeten VPU zu partitionieren, d.h. in ein- 
zelne Teile zu zerlegen, die auf jeweils in die vorhandenen 
Ressourcen abgebildet werden kdnnea. 

Bine Vielzahl derartiger Mechanismen, insbesondere auf Gra- 
phenanalyse basierende, sind nach dem Stand der Technik per se 
bekannt. Eine bevorzugt e Variante basiert jedoch auf der Ana- 
lyse der Programcnsourcen und ist unter dem Begrif f temporal 
Partitioning bekannt. Dieses Verfahren ist in der genannten 
PHD- Thesis von Cardoso beschrieben, die zu Of fenbarungszwecken 
vollumfanglich eingegliedert wird. 

Partitionierungsverf ahren gleich welcher Art sind entsprechend 
des verwendeten VPU-Types zu adaptieren. Liegen VPUs vor, die 
die Speicherung von Zwischenergebniss^n in Register xind/oder 
Speicher zulassen, ist durch die Partitionierung die Einbin- 
dung der Speicher zur Speicherung von Daten und/oder Zustanden 
zu beriicksichtigen. Die Partitioniervmgsalgorithmen (z. B» die 
temporale Partitionierung) sind entsprechend zu adaptieren. 
Gew6hnlicherweise wird die eigentliche Partitionierung und das 
Scheduling durch die genannten Patente jedoch erheblich ver- 
einfacht und erst sinnvoll ermoglicht. 
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Manche VPUs bieten die Moglichkeit der dif f erentiellen Rekon- 
figuration. Diese kann angewendet werden, wenn nur verMltnis- 
m§fiig wenige Andenmgen innerhalb der Anordnung der PAEs bei 
einer Rekonf iguration notwendig werden. Mit anderen Worten 
werden nur die VerSndeningen einer Konf iguration gegeniiber der 
aktuellen Konf iguration rekonfiguriert . Die Partitionierung 
kann in diesem Fall dergestalt sein, daft die auf eine Konf igu- 
ration folgende, gegebenenfalls dif ferentielle Konf iguration 
nur die notwendigen Rekonf igur at ionsdat en enthSlt und keine 
vollstandige Konf iguration darstellt. £s ist mdglich, den Kon- 
figurationsdatenoverhead zu Analysezwecken bei der Beurteilung 
der Aufteilungseffizient mit zu berflcksichtigen. 

Die Schedulingmechanismen fur die partitionierten Codes konnen 
derart erweitert werden, daS das Scheduling durch Ridckmeldun- 
gen der VPU an die jeweils rekonf igurierende Einheit (CT 
und/oder HOSTRECONP) gesteuert wird. Insbesondere wird dabei 
bei der Partitionierung die sich daraus ergebende Mdglichkeit 
der bedingten AusfOhrung, d. h. der expliziten Bestimmung der 
nachfolgenden Partition durch den Zustand der aktuellen Parti- 
tion genutzt. Mit anderen Worten ist es moglich, die Partitio- 
nierung derart zu optimieren, daS bedingte AusfOhrungen* wie z. 
B. ,IF, CASE etc. berucksichtigt werden. 

Werden VPUs verwendet, die die Fahigkeit besitzen Statussigna- 
le zwischen den PAEs zu libertragen, wobei PAEs auf die jeweils 
fibertragenen ZustSnde reagieren und/oder diese mitverarbeiten, 
kann iimerhalb der Partitionierung \ind des Schedulings zudem 
die bedingte Ausfxihrung innerhalb der Anordnung der PAEs, also 
ohne die Notwendigkeit einer vollst^ndigen oder teilweisen Re- 
konf iguration aufgrund eines geSnderten bedingten Pro- 

grammablauf s, berucksichtigt werden. 
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Weiterhin Jcann das Scheduling die Mdglichkeit des Vorladens 
von Konf igurationen w^rend der Laufzeit einer anderen Konfi- 
guration unterstdtzen. Dabei kdnnen mehrere Konfigurationen 
m5glicherweise auch spekulativ vorgeladen warden, d. h. ohne 
dai^ sichergestellt 1st, daS die Konfigurationen flberhaupt be- 
notigt werden. Durch Selektionsmechanismen k5nnen daiin zur 
Laufzeit die zu verwendenden Konfigurationen ausgewUhlt werden 
(siehe auch Beispiel NLS in DE 100 50 442.6, EP 01 102 674.7) 

Eine zusStzliche oder alternative Variante sieht vor, dass die 
Datenverarbeitung innerhalb der an die CPU gekoppelten VPU ex- 
akt gleichviele Takte ben6tigt, wie die Datenverarbeitung in- 
nerhalb der Rechenpipeline der CPU. Insbesondere bei modemen 
Hochleistungs-CPUs mit einer Vielzahl von Pipelinestufen (>20) 
kann dieses Konzept ideal eingesetzt werden. Der besondere 
Vorteil iat, dass kelne besonderen Synchronisationsmechanismen 
wiis z.B. RDY/ACK notwendig sind und/oder keine Anpassung von 
Opcodes zur Registersteuerung erforderlich ist. Der Compiler 
hat bei diesem Verfahren sicherzustellen, dass die VPU die er- 
forderliche Anzahl an Takten einhSlt und ggf . die Datenverar- 
beitxing durch das Einfilgen von Verzdgerungsstufen wie z. B. 
einen Fall -Through FIFOs auszubalancieren wie er in anderen, 
vorerw&hnten Anmeldungen beschrieben ist. 

Der ausgegebene Code ist ublicherweise vollstandig und bevor- 
zugt ohne weitere Eingriffe auf den jeweils nachf olgenden Com- 
pilem verarbeitbar . Gegebenenfalls kdnnen Compilerf lags und 
Constraints zur Steuerung nachfolgender Compiler generiert 
werden, wobei der Anwender falls gewiinscht. optional eigene 
Vorgaben hinzufiigen und/oder die generierten Vorgaben modifi- 
zieren kann. Die nachf olgenden Compiler bendtigen keine we- 
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sentlichen Modif ikationen, so dafi per se bekannte Standard- 
Tools prinzipiell einsetzbar sind. 



Das vorgeschlagene Verfahren eignet sich sorait beispielsweise 
insbesondere als PrSprozessor bzw, PrSprozeasorverfahren vor 
Compilem und Entwicklungssystemen. Es soil aber ausdrflcklich 
erwahnt werden, da& prinzipiell anstatt und/oder zusammen mit 
den zuvor beschriebenen Obersetzers- auch Compiler nach PACTll 
eingebunden warden konnen. 

An die beschrlebene Architektur, insbesondere direkt an die 
VPU kann ein FPGA gekoppelt sein, urn feingranulare Datenverar* 
beitiang zu ermoglichen und/oder ein flexibel adaptierbares In- 
terface (z.B. diverse serielle Schnittstellen (V24, USB, 
etc.), diverse par allele Schnittstellen, Festplattenschnitt- 
stellen, Ethernet, Telekommxinikationsschnittstellen (a/b, TO, 
ISDN, DSL, etc)) zu weiteren Baugruppen zu erm6glichen . 
Der FPGA kann dabei aus der VPU- Architektur, insbesondere 
durch die CT, und/oder durch die CPU konfiguriert werden. Der 
FPGA kann statisch, also ohne Rekonf iguration zur Laufzeit 
und/oder dynamisch, also mit Rekonf iguration zur Laufzeit, be- 
trieben werden. 

Es wurde bereits das Vorsehen eines Interface-Code angespro- 
chen. Der Interface -Code, der in den extrahierten Code einge- 
setzt wird, kann durch unterschiedliche Verfahren vorgegeben 
werden. Bevorzugt wird der Interface-Code in einer Datenbank 
abgelegt, auf die zugegriffen wird. Die Einheit zur Umsetzung 
kann so ausgebildet sein, daS sie eine Auswahl, etwa des Pro- 
graniinierers, beriicksichtigt , bei der beispielsweise durch Hin- 
weise im PRCXSRAMM Oder durch Compilerf lags der passende Inter- 
face-Code ausgewShlt wird. Dabei kann ein fiir das jeweils ver- 
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wendete Implement ierungsverfahren des VPU/CPU-Systems geeigne- 
ter Interface -Code gewShlt werden.. 



Die Datenbank selbst kann durch unterschiedliche Methoden auf- 
gebaut und gewartet werden. Einige Belspiele sollen zur Ver- 
deutlichung der MSglichkeiten angefflhrt werden: 

a) Der Interface -Code kann vom Lieferanten des Compilers fClr 
bestimmte Verbindungsverfahren zwischen VPtJ und CPU(s) 
vorgegeben werden. Dies kann bei der Organisation der Da- 
tenbank benicksichtigt werden, indem entsprechende Spei- 
chermittel fir diese Angaben bereitgehalten werden. 

b) Der Interface -Code kann vom Benutzer, der den Systemaufbau 
bestimmt hat, selbst geschrieben oder aus bestehenden 
(Beispiel-) Interface -Code modifiziert und der Datenbank 
zugefugt werden. Das Datenbankmittel wird hierzu bevorzugt 
benutzermodifizierbar gestaltet, um dem Benutzer die Da- 
tenbankmodifikation zu ermdglichen. 

c) Der Interface-Code kann von eine Entwicklungssystem, mit 
dem beispielsweise der Systemaufbau des VPU-CPU- Systems 
geplant uhd/oder beschrieben und/oder getestet wurde, au- 
tomatisch generiert werden. 

Der Interface-code ist gewiShnlicherweise bevorzugt derart ge- 
staltet, daS er den Anf orderungen- der Programmiersprache ent- 
spricht, in der der extrahierte Code vorliegt in den der In- 
ter£ace-Code eingefiigt werden soil. 

Debugging und Integration der Toolsets 

In die Interface- Codes kdnnen Kommunikationsroutinen einge- 
fuhrt werden, um die xinterschiedlichen Entwickiungssysteme fiir 
PR02ESS0R und VPU zu synchronisieren. Insbesondere kauin Code 
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fur die jeweiligen Debugger (z. B. nach PACTll) aufgenotninen 
werden. 



Der Interface -Code ist so ausgebildet, dafi er den Datenaus- 
tausch zwischen PR02BSS0R und VPU erm6glicht und/oder steuert. 
Er ist daher eine geeignete und bevorzugte Schnittstelle, um 
die jeweiligen Entwicklungssysteme und Debugger zu steuem. Es 
ist beispielsweise m6glich, einen Debugger fttr den PROZESSOR 
isolange zu aktivieren, wie die Daten von dem Prozessor verar- 
beitet werden. Sobald die Daten fiber den Interface -Code an ei- 
ne (Oder mehrere) VPU flbergeben werden, ist ein Debugger fiir 
VPUs zu aktivieren. Wird der Code zuriick an den PROZESSOR ge- 
sendet, soil wiederum der PROZESSOR-Debugger aktiviert werden. 
Es ist daher silso mSglich \md bevorzugt, derartige Abl^ufe 
durch das Einffigen von Steuercodes fUr Debugger und/oder Ent- 
wicklungssysteme in den Interface-Code abzuwickeln. 

Die Konununikation und Steuerung zwischen den unterschiedlichen 
Entwicklungssysteraen soli daher bevorzugt mittels in die In- 
terface-Codes von PROZESSOR und/oder VPU eingebrachte Steuer- 
codes abgewickelt werden. Die Steuercodes kSnnen dabei beste- 
henden Standards fur die Steuerung von Entwicklungssystetnen 
weitgehend entsprechen. 

Die Verwaltung und Kommunikation der Entwicklungssysteme wird 
vorzugsweise wie beschrieben in die Interface -Codes abgewik- 
kelt,.kann jedoch - sofem sinnvoll - auch getrennt von die- 
sen, nach einem entsprechenden ahnlichen Verf eOiren abgewickelt 
werden. 

In vielen Programmiersprachen, besonders in sequentiellen wie 

z. B. C, wird eine.exakte zeitliche Reihenfolge implizit durch 

die Sprache vorgegeben. Bei sequentiellen Progrannniersprachen 
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geschieht dies beispielsweise durch die Reihenfolge der ein- 
zelnen Anweisungen. Sofern durch Programmiersprache tmd/oder 
den Algorithmus erforderlich, lafit sich die Ze it information 
auf Synchronisationsmodelle wie RDY/ACK und/oder REQ/ACK oder 
ein Time -S tamp- Verfahren abbilden. 

Beispielsweise wird eine nachfolgende for-Schlei£e nur daim 
durcblaufen und iteriert; wenn eine Variable, hier input stream 
je Durchlauf mit einem RDY quittiert ist. Bleibt RDY aus, wird 
der Schleifendurchlauf bis zum Eintreffen RDY angehalten: 

while TRUE- 
s 1= 0 

for i: 1 to 3 

s ;a s + inputstream; 

Die Eigenschaft der sequentiellen Sprachen, nur von der Be- 
fehlsverarbeitung gesteuert zu werden, wird mit dem Datenflxifi- 
prinzip die Verarbeitung durch den Datenstrom, bzw. die Bxi- 
stenz von Daten zu steuem verbunden- Mit anderen Worten wird 
ein Befehl und/oder eine Anweisung (z. B. s :« s + 
inputstream;) nur verarbeitet, wenn die Operation ausgefflhrt 
iWerden kann uiid die Daten verffigbar sind. 

Bemerkenswert ist, daS dieses Verfahren gewdhnlicherweise zu 
keiner Anderung der Syntax oder Semsmtik einer Hochsprache 
f dhrt . 

Komplexere Funktionen einer Hochsprache/ wie z. B, Schleifen, 
warden durch Makros realisiert. Die Makros werden vom Compiler 
vorgegeben \md zur Ubersetzungszeit instantiiert . 
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Die Makros sind entweder aus einfachen Sprachkonstrxikten der 
Hochsprache oder auf Assembler level aufgebaut. Makros konnen 
parametriert sein, urn eine einfach Adaption an den beschriebe- 
nen Algorithraus zu ermoglichen. (vgl. auch PACTll) 

Ein Standardprozessor z.B. ein RISC, CISC, DSP (CPU) wird also 
mit einem rekonf igurierbaren Prozessor (VPU) gekoppelt. 

Zwei vinterschiedliche, bevorzugt jedoch auch zugleich imple- 
mentierbare Kopplimgsvarianten konenn wie folgt beschrieben 
sein. 

Eine erste Variante sieht eine direkte Ankoppelung an den Be- 
fehlssatz einer CPU vor (Befehlssatzkoppltmg) . 
Eine zweite Variante sieht eine Ankoppelung fiber Tabellen im 
Hauptspeicher vor. Es sind also Tabellenmittel vorgesehen. 

Innerhalb eines Instruktionssatzes (ISA) einer CPU sind fur 
gewohnlich freie xmbenutzte Befehle vorhanden. Einer oder eine 
Mehrzahl dieser freien unbenutzen Befehle wird nunmehr fCir die 
Steuerung von VPUs verwendet (VPUCODE) . 

Durch die Dekodierung eines VPUCODEs wird eine Konf igurations- 
. einheit (err) einer VPU angesteuert die in Abhangigkeit des 
VPUCODEs bestimmte. AblSufe ausfuhrt. Es ist also eine zur VPU- 
Decodierung ansprechbare CT vorhanden. 

Beispielsweise kann ein VPUCODE das Laden land/oder Ausfuhren 
von Konfigurationen durch die Konf igurat ions einheit (CT) fHx 
eine VPU auslosen. 
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In einer erweiterten Ausfuhrung kann ein VPUCODE uber eine 
Ubersetzungstabelle, die bevorzugt von der CPU, altemativ 
aber auch von der Oder einer VPU oder einer extemen Einheit 
aus verwaltet vird, auf unterschiedliche VPU-Koinmandos uber- 
setzt verden 

Die Konfigurationstabelle kann in Abh^gigkeit von dem ausge- 
fCLhrten CPU Prograram oder Codeabschnitt gesetzt werden. 

Die VPU ladt nach Eintreffen eines Ladekommandos Konfiguratio- 
nen aus einem eigenen oder mit der CPU geteilten Speicher. 
Insbesondere kann eine VPU-Kon£iguration im Code des aktuell 
ausgefiihrten CPU- Programmes beinhaltet sein. 

Nach Erhalt eines Ausfuhrungskommandos fvihrt eine VPU die aus- 
zuftorende Konf iguration aus und die entsprechende Datenverar- 
bieitung durch. Das Beenden der Datenverarbeitxing kann durch 
ein Terminierungssignal (TERM) an die CPU angezeigt werden. 
Dazu sind entsprechende Signalleitungen/Interrupt-Eing&nge 
usw. vorhanden und/oder; ausgebildet. 

Das Auftreten eines VPUCODEs kdnnen solange Wartezyklen auf 
der CPU ausgeffihrt werden, bis das Terminierungssignal (TERM) 
der Beendigung* der Datenverarbeitung von der VPU eintrif f t . 

In einer bevorzugten Ausgestaltxing wird mit der Verarbeitung 
der nSchsten Codes fortgefahren. Tritt ein weiterer VPUCODE 
auf, kann sodcoin auf die Beendigung des vorhergehenden gewar- 
tet werden, oder sSmtliche gestartete VPUCODEs werden in einer 
Verarbeitungspipeline eingereiht, oder ein Taskwechsel wird 
insbesondere wie nachfolgend beschrieben ausgef^ihrt. 
Die Beendigung einer Datenverarbeitung wird durch das Eintref- 
fen des Terminierungssignal (TERM) in einem Statusregister si- 
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gnalisiert. Die Terminieaningssigiiale treffen in der Reihenfol- 
ge einer mdglichen Verarbeitungspipeline ein. 



Die Datenverarbeitung auf der CPU kann durch das Testen des 
Statusregisters auf das Eintreffen eines Terminierungssignales 
synchronisiert werden. 

In einer mdglichen Ausgestaltung kann, sofem eine Applikation 
vor dem Eintreffen von TERM z.B. durch Datenabhingigkeiten 
nicht fortgesetzt werden kann, ein Taskwechsel ausgel6st wer- 
den. 

Es ist bevorzugt, wenn lose Kopplungen zwischen. Prozessoren 
und VPUs aufgebaut sind, bei welchen VPUs weitestgehend als 
unabhSngige Coprozessoren arbeiten. 

Eine derartige Kopplung sieht eine oder mehrere gemeinsame Da- 
tenquellen \md -senken, zumeist toer gemeinsame Bussysteme 
und/oder gemeinsame Speicher vor, fiber DMAs und/oder andere 
Speicherzugrif fskontroller werden Daten zwischen einer CPU und 
einer VPU ausgetauscht - Die Synchronisation der Datenverarbei- 
txmg erfolgt bevorzugt Ober eine Interruptsteueriang oder einen 
Statusabfragemechanismus (z.B. Polling) . 

Eine enge Ankopplung entspricht der vorab beschriebenen direk- 
ten Ankopplung einer VPU in den Befehlssatz einer CPU. 

Bei einer direkten Rechenwerk -Ankopplung ist besonders auf ei- 
ne hohe Rekonf igurationsperformance zu achten. Bevorzugt kann 
daher die Wave-Rekonf iguration zum Einsatz kommen. Desweiteren 
werden die Konfigurationsworte bevorzugt vorab derart vorgela- 
den, dass bei Ausf(Uirung des Befehls die Konf iguration beson- 
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ders schnell (mittels Wave -Reconfiguration ira Optimalfall in- 
nerhalb eines Taktes) konfiguriert werden kann. Im ubrigen wa- 
re auch moglich, anstelle einer Array-Teilkonf iguration bei 
hoch performanten, insbesondere aber auch bei uberwiegend nie- 
derperformanten Anwendungen mehrere insbesondere identische 
Arrays vorzusehen, von diesen wenigstens eines f\ir eine neue 
Task umzukonfigurieren, insbesondere im Vorgriff , und dann 
nach Bedarf anstelle einer Umkonfiguration oder Teilurakonf igu- 
ration eines integralen multidimensionalen partiell zur Lauf- 
zeit rekonf igurierbaren grobgranularen Feldes einf ach auf ein 
anderes Array vollstSndig zu wechseln. Signale kdnnen dabei z. 
B. fiber MDX-/Demuxstufen den Teilarrays zugefuhrt werden, ins- 
besondere I/O-, Daten-, Status- und/oder Triggersignale . 

Ffir die Wave -Reconfiguration werden bevorzugt die voraussicht- 
lich auszufuhrenden Konfigurationen vorab durch den Compiler 
zur Corapilezeit erkannt \md zur Laufzeit entsprechend vorgela- 
den. 

Zum Zeitpunkt der Bef ehlsausffihrung wird die entsprechende 
Konfiguration gegebenenfalls ffir jede PAE einzeln iind/oder ffir 
eine PAE-Teilmenge einzeln selektiert und ausgefuhrt. Auch 
derartige Verfahren sind nach den o.g. Schriften bekannt. 

Eine bevorzugte Implementierung kann tuiterschiedliche Daten- 
transfers zwischen einer CPU und VPU yorsehen! Drei besonders 
bevorzugte einzeln oder kombiniert einsetzbare Methoden werden 
nachfolgend beschrieben. 

Bei einer Regis terkopplung kann die VPU Daten aus einem CPU- 
Register entnehmen, verarbeiten und in ein CPU- Register zu- 
riickschreiben . 
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Bevorzugt werden Synchronisationsmechanismen zwischen der CPU 
xind der VPU eingesetzt. 



Beispielsweise kaim die VPU durch das Einschreiben der Daten 
in ein CPU-Register durch die CPU ein RDY-Signal erhalten und 
daraufhin die eingeschriebenen Daten verarbeiten. Das Auslesen 
von Daten aus einem CPU-Register durch die CPU kann ein ACK- 
Signal generieren, wodurch die Datenabnahme durch die CPU der 
VPU signalisiert wird. Die Verwendung des per se bekannten 
RDY/ACK-Protokolls in unterschiedlicher AusprSgung ist vorlie- 
gend gerade bei grobgranularen Zellen der rekonf igurierbaren 
Einheiten vorteilhaft. 

CPUs stellen typischerweise keine entsprechenden Mechanismen 
2ur Verfugung. 

Zwei mdgliche Losungen werden naher beschrieben: 

Ein einfach zu realsierenden Ansatz ist, die Datensynchronisa- 
tion uber ein Statusregister durchzufiihren. Beispielsweise 
kanh die VPU das erfolgte Auslesen von Daten aus einem Regi* 
ster und das damit verbundene ACK-Signal und/oder das Ein- 
schreiben. von Daten in ein Register und das damit verbundene 
RDY-Signal in dem Statusregister anzeigen. Die CPU testet zu- 
nachst das Statusregister imd fuhrt beispielsweise so lange 
Warteschleifen oder Taskwechsel aus, bis - je nach Operation - 
das RDY oder ACK eintraf . Danach fuhrt die CPU den jeweiligen 
Registerdatentransfer aus. 

In einer earweiterten Ausgestaltung wird der Befehlssatz der. 
CPU urn load/store- Instruktionen mit integrierter Statusabfrage 
(ioad_rdy, store_ack) erweitert. Beispielsweise. wird bei einem 
store_ack nur dann ein neues Datenwort in ein CPU-Register ge- 
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schrieben, wenn das Register vorher von der VPU ausgelesen 
wurde und ein ACK eintraf . Entsprechend liest load_rdy nur Da- 
ten aus einem CPU-Register, wenn die VPU vorher neue Daten 
eingeschrieben und ein RDY generiert hat. 

Daten, die zu einer auazufuhrenden Konfiguration gehdren kdn- 
nen sukzessive, quasi durch Block-Moves Shnlich wie nach dem 
Stand der Technik in die CPU-Register geschrieben und/oder aus 
diesen gelesen werden, Ggf . implementierte Block-Move- 
Instruktionen konnen bevorzugt durch die beschriebene inte- 
grierte RDY/ACK Statusabfrage erweitert werden. 

Es ist of fensichtlich, dass eine Vielzahl von leichten Modifi- 
kationen und unterschiedlichen Ausgestaltungen dieses Grund- 
verfahrens mdglich sind. 

Die bereits erwShnte Wave-Rekonfiguration erlaubt das Starten 
eines neuen VPU-Befehls und der entsprechenden Konfiguration, 
sobald die Operanden des vorhergehenden VPU-Befehls aus den 
CPU-Registem abgenommen wurden. Die Operanden fiir den neuen 
Befehl kdnnen direkt nach Befehlsstart in die CPU-Register ge- 
schrieben werden. 

Entsprechend des Wave-Rekonf iguration-Verf ahrens wird die VPU 
successive mit Pertigstellung der Datenverarbeitung des vorhe- 
rigen VPU-Befehls fur den neuen VPU-Befehl umkonf iguriert und 
die neuen Operanden verarbeitet. 

Weiterhin konnen Daten zwischen einer VPU und einer CPU durch 
geeignete Buszugrif fe auf gemeinsame Ressourcen ausgetauscht 
werden . 
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Sofern Daten ausgetauscht werden sollen, die kurz zuvor von 
der CPU verarbeitet wurden und daher voraussichtlich noch im 
bevorzugt vorzusehenden Cache der CPU liegen bzw. sofort an- 
schliessend von der CPU verarbeitet werden und daher sinnvol- 
lerweise in den Cache der CPU gelegt werden, werden diese be- 
vorzugt von der VPU aus dera Cache der CPU gelesen, bzw. in den 
Cache der CPU geschrieben. Dies kann durch geeignete Analysen 
weitestgehend vorah zur Cotnpilezeit der Applikation durch den 
Compiler festgestellt und der Bin&rcode entsprechend generiert 
werden. 

Sofern Daten ausgetauscht werden sollen, die sich voraussicht* 
lich nicht im Cache der CPU befinden bzw. voraussichtlich 
nicht nachfolgend im Cache der CPU benStigt werden, werden 
diese bevorzugt von der VPU direkt vom extemen Bus und der 
damit verbundenen Datenquelle (z.B. Speicher, Peripherie) ge- 
lesen, bzw. an den extemen Bus und der damit verbundenen Da- 
tensenke (z.B. Speicher, Peripherie) geschrieben. Dies kann 
durch geeignete Analysen weitestgehend vorab zur Compilezeit 
der Applikation durch den Compiler festgestellt und der Bin&r- 
code entsprechend generiert werden. 

Bei einem Trsuisfer Ciber den Bus am Cache vorbei wird bevorzugt 
ein Protokoll zwischen Cache und Bus impleraentiert , das fiir 
einen korrekten Inhalt des Caches sorgt. Beispielsweise kann 
das bekaimte MESI -Protokoll nach dem Stand der Technik hierzu- 
verwendet werden. 

Die beschriebenen Verfahren m^lssen zunSchst keinen besonderen 
Mechanismus fur die Unterstutzung von Betriebssystemen vorse- 
hen. Es ist n^mlich bevorzugt, sicherzustellen, dass ein aus- 
zufuhrendes Betriebssystem sich entsprechend des Status einer 
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zu unterstutzenden VPU verhdlt, was moglich ist and wozu ins- 
besondere Scheduler vorgesehen sein koimen. 



Bei einer engen Rechenwerkkoppliing wird bevorzugt das Status - 
register der CPU abgefragt, in welches die angekoppelte VPU 
ihren Datenverarbeitungsstatus (Terminierungssignal) eintrSgt. 
Soil eine weitere Datenverarbeitung an die VPU fibertragen wer- 
den, und die VPU hat die vorherige Datenverarbeitung noch 
nicht beendet wird gewartet und/oder bevorzugt ein Taskwechsel 
ausgefflhrt. 

PQr eine Coprozessorkoppl\mg werden bevorzugt uber das Be- 
triebssystem, i.b. den Scheduler gesteuerte Mechanismen ver- 
wendet : 

Ein einfacher Scheduler kaim nach Obertragung einer Funktion 
auf eine VPU entweder den aktuellen Task auf der CPU weiter- 
laufen lassen, sofern dieser xinabhSngig und parallel zur Da- 
tenverarbeitung auf einer VPU ablaufen kann. Sofern oder so- 
bald der Task auf die Beendigung der Datenverarbeitung auf der 
VPU warten muss, schaltet der Taskscheduler auf einen anderen 
Task um. 

Jeder neu aktivierte Task wird, sofern er die VPU verwendet, 
vor Verwendung prCkfen, ob diese fflr eine Datenverarbeitung zur 
Verffigxing steht und/oder aktuell noch Daten verarbeitet; dann 
soli entweder auf die Beendigung der Datenverarbeitung gewar- 
tet Oder bevorzugt der Task gewechselt werden. 

Ein einf aches und dennoch leistungsfahiges Verfahren kann 
durch sogenannte Descriptor Tables aufgebaut werden, die be- 
spielsweise f olgendermafien realisiert werden kdnnen: 
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Jeder Task generiert zum Aufruf der VPU eine Oder mehrere Ta- 
belle(n) (VPUCALL) mit einem geeigneten festgelegten Datenfor- 
mat in dem ihm zugewiesenen Speicherbereich. Diese Tabelle be- 
einhaltet sSmtliche Steuerinfoirmation fiir eine VPU, wie z.B. 
das auszufilhrende Programm / die auszufxihrende Konfiguration 
und/oder Zeiger au£. die Speicherstelle (n) oder Datenguellen 
der Eingangsdaten und/oder die Speicherstelle (n) oder Daten- 
senken der Ergebnisdaten und/oder weitere Ausfflhrungsparame- 
ter, z.B* DatenarraygrdSen. 

Im Speicherbereich des Bet riebssys terns befindet sich eine Ta- 
belle Oder verkettiBte Liste (LINKLIST) , die auf sSmtliche 
VPUCALL-TcdDellen in der Reihenfolge ihrer Erstellung zeigt. 

Die Datenverarbeitxmg auf der VPU ISuft nunmehr derart ab, 
dass ein Task einen VPUCALL erstellt und fiber das Betriebssy- 
stem die VPU aufruft. Das Be triebs system erstellt einen Eln* 
trag in der LINKLIST. Die VPU arbeitet die LINKLIST ab und 
fuhrt die jeweils referenzierten VPUCALL aus. Die Beendigung 
einer der jeweiligen Datenabarbeltung wird jeweils durch einen 
entsprechenden Eintrag in die LINKLIST und/oder VPUCALL Tabel- 
le angezeigt. 

Die VPU arbeitet somit weitgehend unabh^ngig von der CPU. Das 
Betriebssystem und/oder die jeweiligen Task miissen lediglich 
die Tabellen (LINKLIST bzw. VPUCALL) uberwachen. 

Besonders perfoirmanceef f izient arbeiten die beiden Verfahren, 
wenn als VPU eine Architektur zum Einsatz kommt, die eine mit 
der Datenverarbeitung Ciberlagerte und/oder tiberlagerbare Re- 
konfiguration zul&sst. 
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Damit ist es moglich, eine neue Datenverarbeitung iind eine 
ggf . damit verb\indene Rekonf iguration sofort nach Lesen der 
letzten Operanden aus den Datenquellen zu starten. Mit anderen 
Worten ist fur die Synchronisation nicht mehr das Beenden der 
Datenverarbeitiing, sondem das Lesen der letzten Operanden er- 
forderlich. Dadurch wird die Performance der Datenverarbeitung 
erheblich gesteigert* 

inen zuscLtzlichen Einflufl auf die Betrachtung und den Umgang 
mit Zustanden hat der m5gliche Einsatz eines Betriebssystemes. 
Betriebssysteme verwenden beispielsweise Task-Scheduler zum 
Verwalten mehfere Aufgaben (Tasks), um ein Multitasking zur 
VerfUgung zu stellen. 

Task-Scheduler brechen Tasks zu einem bestimmten Zeitpunkt ab/ 
starten andere Tasks und kehren nach deren Abarbeitung zur 
Weiterbearbeitung des abgebrochenen Tasks zurUck. 
Sofern sichergestellt ist, daB eine Konf iguration - die der 
Abarbeitung eines Tasks entspricht - nur nach der kompletten 
Abarbeitung - d.h. wenn alle innerhalb dieses Konf igurations- 
zyklusses zu bearbeitende Daten und Zustande gespeichert sind 
- terminiert, kOnnen lokal relevante Zustande ungespeichert 
bleiben. 

Sofern der Task-Scheduler allerdings Konf igurationen vor deren 
vollstandiger Abarbeitung abbricht, miissen lokale Zustande 
und/oder Daten gespeichert werden. Weiterhin ist dies von Vor-- 
teil, wenn die Abarbeitungszeit einer Konf iguration nicht vor- 
hergesagt werden kann. In Verbindung mit dem bekannten Halte- 
problem und dem Risiko, daB eine Konfiguration (z.B. durch ei- 
nen Fehler) gar nicht terminiert/ erscheint dies weiterhin 
sinnvollr um damit einen Deadlock des gesamten Systems zu ver- 
hindern. 

Mit anderen Worten sind, unter Berticksichtung von Taskwech- 
seln, relevante Zustande auch als solche anzusehen, die fiir 
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einen Taslcwechsel und ein erneutes korrekes Aufsetzen der Da- 
tenverarbeitung notwendig sind. 

Bei einem Taskswitch ist somit der Speicher ftir Ergebnisse und 
ggf . auch der Speicher fxir die Operanden zu sichern und zu ei- 
nem spateren Zeitpunkt, also bei der Riickkehr zu diesem Task, 
wieder herzustellen. Dies kann vergleichbar zu den PUSH/POP 
Befehlen und Verfahren nach dem Stand der Technik erfolgen. 
Weiterhin ist der Zustand der Datenverarbeitung zu sichern, 
also der Zeiger auf die zuletzt vollstSndig bearbeiteten Ope- 
randen. Es sei hier besonders auf PACT18 verwiesen. 

Abhangig von der Optimierung des Taskswitches gibt es bei- 
spielsweise zwei Moglichkeiten: 

a) Die abgebrochene Konf iguration wird neu konfiguriert und 
nur die Operanden werden geladen. Die Datenverarbeitung be- 
ginnt von neuem, als ob die Bearbeutung der Konf iguration noch 
gar nicht begonnen vrurde. Mit anderen Worten werden einfach 
alle Datenberechnungen von vorne an ausgefUhrt, wobei ggf. Be- 
rechnungen bereits zuvor durchgefahrt warden. Diese M5glich- 
keit ist einfach aber nicht sehr effizient. 

b) Die abgebrochene Konf iguration wird neu konfiguriert, wobei 
die Operaden und bereits berechneten Ergebnisse in die jewei- 
ligen Speicher geladen werden. Die Datenverarbeitung wird bei 
den ^Operanden ; fortgesetzt die nicht mehr vollstandig berechijet 
wurden. Dieses Verfahren ist sehr viel effizienter, setzt aber 
voraus, dafi ggf. zusStzliche ZustSnde die wShrend der Verar- 
beitung der Konfiguration entstehen relevant werden, bei- 
spielsweise muB zumindest ein Zeiger auf die zuletzt vollstan- 
dig verechneten Operanden gesichert werden, damit bei deren 
Nachfolgern nach erfolgter neuer Konfiguration. neu aufgesetzt 
werden kann. 

Eine besonders bevorzugte Variante zur Verwaltung von relevan- 

ten Daten wird durch den nachfolgend beschriebenen Kontext 

Switch zur Verfiigung gestellt, Bei Task-Wechseln und/oder bei 
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der AusfUhrung von Konf igurationen und dereiti Wechsel (siehe 
beispielsweise Patentanmeldung PACT15, die zu Of f enbarungs- ■ 
zwecken vollumfSnglich eingegliedert ist) kann es erforderlich 
sein, Daten oder Zustande, die typischerweise nicht zusainmen 
mit den Arbeitsdaten in die Speicher abgelegt werden, da sie 
beispielsweise lediglich einen Endwert markieren, fur eine 
nachfolgende Konf igurat ion zusichern. 

Der erf indungsgeiQaBe Kontext Switch wird derart durchgefiihrt, 
dass eine erste Konf iguration entfernt wird, die zu sichernden 
Daten verbleiben in den entsprechenden Speichern (REG) (Spei- 
cher, Register, ZShler, etc) . 

Eine zweite Konf iguration wird geladen, diese verbindet die 
REG in geeigneter Weise und definierter Reihenfolge rait einem 
Oder mehreren globalen Speicher (n). 

Die Konfiguration kann beispielsweise Adressgeneratoren ver- 
wenden urn auf den/die globalen Speicher zuzugreifen. 
Die Konfiguration kann beispielsweise Adressgeneratoren ver- 
wenden um auf als Speicher ausgestaltete REG zuzugreifen. 
Entsprechend der konfigurierten Verbindung zwischen den REG 
werden die Inhalte der REG in einer definierten Reihenfolge in 
den globalen Speicher geschrieben, wobei die jeweiligen Adres- 
sen von Adressgeneratoren vorgegeben werden. Der Adressgenera- 
tor generiert die Adressen fQr den/die globalen Speicher (n) 
derart, dass die beschriebenen Speicherbereiche (PUSHAREA) der 
entfernten ersten Konfiguration eindeutig zugeordnet werden 
kdnnen . 

Mit anderen Worten, es sind bevorzugt fiir unterschiedliche 
Konf igurationen unterschiedliche AdressenrSume vorgesehen- Die 
Konfiguration entspricht einem PUSH gew6hnlicher Prozessoren. 

Danach verwenden andere Konf igurationen die Ressourcen. 

Die erste Konfiguration soil wieder gestartet werden. Zuvor 

wird eine dritte Konfiguration gestartet, die die REG der er- 
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sten Konfiguration in einer definierten Reihenfolge miteinan- 
der verbindet. 

Die Konfiguration kann beispielsweise Adressgeneratoren ver- 
wenden mti auf den/die globalen Speicher zuzugreifen. 

Die Konfiguration Jcann beispielsweise Adressgeneratoren ver- 
wenden urn auf als Speicher ausgestaltete REG zuzugreifen. 

Ein Adressgenerator generiert Adressen derart, dass ein kor- 
rekter Zugrif f auf die der ersten Konfiguration zugeordnete 
PUSHAREA erfolgt. Die generierten Adressen und die konfigu- 
rierte Reihenfolge der REG sind derart, dass die Daten der REG 
in der ursprtinglichen Ordnung aus den Speichern in die REG ge- 
schrieben werden. Die Konfiguration entspricht einem POP ge- 
w5hnlicher Prozessoren. 

Die erste Konfiguration wird wieder gestartet. 

Zusammengef^i&t wird ein Kontext Switch derart durchgefUhrt, 
dass durch das Laden besonderer Konf iguratlonen, die ^hnlich 
von PUSH/POP bekannter Prozessorarchitekturen atbeiten, die zu 
sichernden Daten mit einezn globalen Speicher ausgetauschen 
werden. 

Die Funktion soil in einem Beispiel verdeutlicht werden: 

Eine Funktion addiert 2 Zahlenreihen, die LMnge der Reihen ist 

zur Obersetzungszeit nicht bekannt, sondern erst zur Laufzeit. 

proc example 

while Klength do 
x[il = ati] + bti] 

Die Funktion wird nun wfihrend ihrer Ausfuhrung unterbrochen, 

beispielsweise durch einen Tas k- Switch oder weil der fUr x 
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vorgesehene Speicher voll ist. a,b,x befinden sich zu diesem 
Zeitpunkt erf indungsgemaB in Speichern. i und ggf . length mils- 
sen jedoch gesichert werden. 

Dazu wird die Konfiguration example terminiert, wobei die Re- 
gisterinhalte erhalten bleiben und eine Konfiguration push ge- 
startet, die i und length aus den Regis tern liest und in einen 
Speicher schreibt. 

proc push 

mem[<push_adr_example>] = i 
push_adr_example++ 
mem[<push_adr_example>] « length 

Nach der Ausfuhrung wird push terminiert und die Registerin- 
halte konnen gelbscht werden. 

Andere Konf igurationen werden ausgefuhrt. Nach einiger Zeit 
wird die Konfiguration example wieder gestartet. 
Zuvor wird eine Konfiguration pop gestartet, die die Registe- 
rinhalte wieder aus dem Speicher liest. 

proc pop 

i = mem[<push_adr_exainple>] 

push_adr_example++ 

length = mem[<push_adr_example>] 

Nach der Ausftihrung wird pop terminiert und die Registerinhal- 
te bleiben bestehen. Die Konfiguration example wird wieder ge- 
startet 

Beschreibung der Figuren 

Figur 1 verdeutlicht ein Beispiel das vorgeschlagene Verfahren 
und zeigt einen mdglichen Systemaufbau. Dabei ist ein PROZES- 
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SOR (0101) aber ein geeignetes Interface (0102) zum Daten- und 
Status-austausch mit einer VPU (0103) verbunden. 
Ein PROGRAMM-Code (0110) wird (z. B. durch einen Praprozessor 
fur einen Compiler) beispielsweise gemaS den beschriebenen Ex- 
traktionsmethoden in einen fur den PROZESSOR geeigneten Teil 
(0111) und einen VPU-geeigneten Teil (0112) zerlegt. 

0111 wird durch einen dem PROGRAMM-Code entsprechenden Stan- 
dard Compiler (0113) ubersetzt, wobei zuvor der zusatzliche 
Code zur Beschreibung und Verwaltung des Interfaces (0102) 
zwischen dem PROZESSOR und einer VPU aus einer Datenbank 
(0114) eingefQgt wird. Auf 0101 ausfflhrbarer sequent ieller 
Code wird generiert (0116) und sofem notwendig die entspre- 
chende Programmierxing (0117) des. Interfaces (0102) . 

Der Standard-Compiler kann dergestalt sein, daS er als 
markt^ibliches W^rkzeug oder im Rahmen einer markt<lblichen Ent- 
wicklxmgsumgebxmg vorliegt. Der Praprozessor und/oder m6gli- 
cherweise der VPU-Compiler und/oder mdglicherweise der Debug- 
ger und weitere Werkzeuge kdnnen beispielsweise in eine beste- 
hende marktubliche Entwicklungsumgebung integriert warden* 

0112 wird durch einen VPU Compiler (0115) libersetzt, wobei zu- 
satzlicher Code zur Beschreibung und Verwaltung des Interfaces 
(0102) aus einer Datenbank (0114) eingefflgt wird. Auf 0103 
ausffihrbare Konf igurationen werden generiert (0118) und sofem 
notwendig die entsprechende Programmierung (0119) des Interfa- 
ces (0102). Es soli ausdrflcklich erwahnt werden, daS prinzipi- 
ell auch Compiler nach DE 101 39 170.6 fiir 0115 verwendet wer- 
den kdnnen. 

In Figxir 2 ist beispielhaft ein prinzipieller Ablauf einer 
Compilation dargestellt. Ein PROGRAMM (0201) wird in der Ex- 
traktionseinheit (0202) nach unterschiedlichen Verfahren in 
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VPU-Code (0203) und PROZESSOR-Code (0204) zerlegt. Unterschied- 
liche Methoden konnen in beliebiger Kombination zur Extraktion 
angewendet werden, beispielsweise Hinweise im ursprilnglichen 
PROGRAMM (0205) iind/oder Unterprogrammauf rufe (0206) und/oder 
Analyseverfahren (0207) und/oder eine Verwertimg von objekt- 
orientierten Klassenbibliotheken (0206a) • Der jeweils extra- 
hierte Code wird ggf . flbersetzt und ggf . auf seine Eignung ffir 
das jeweilige Zielsystem bin ilberpruft (0208) . Dabei ist eine 
Rflckkopplung (0209) auf die Extraktion moglich, urn Verbesse- 
ningen durch eine geSnderte Zuordnung der Codes zu einem PRO- 
ZESSOR Oder einer VPU bzw. einer Vielzahl derselben zu erhal- 
ten. 

Danach (0211) wird 0203 durch den Interface- Code aus einer Da- 
tenbank (0210) erweitert (0212) und/oder 0204 wird durch den 
Interface-Code aus 0210 zu 0213 erweitert. 
Der entstandene Code wird auf seine Performance analysiert 
(0214), ggf. ist eine RCIiclckopplung (0215) auf die Extraktion 
m&glich, urn Verbesserungen durch eine geSnderte Zuordnung der 
Codes zum PROZESSOR oder einer VPU zu erhalten. 
Der entstandene VPU-Code (0216) wird fdr eine weitere flberset- 
zung an einen nachgeschalteten fur die VPU geeigneten Compiler 
weitergegeben. Der entstandene PROZESSOR- Code (0217) wird fflr 
die weitere Obersetzung in einem beliebigen nachgeschalteten 
fflr den PROZESSOR geeigneten Compiler weiterverarbeitet . 

Es soli angemerkt werden, dafi' einzelne Schritte je nach Ver- 
fahren ausgelassen werden konnen. Wesentlich ist, dafi ein zu- 
mindest weitgehend kompletter und ohne, wenigstens ohne signi- 
fikanten Eingriff durch den Programmierer direkt ubersetzbarer 
Code an jeweils nachgeschaltete Compilersysteme ausgegeben 
wird. . 
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Es wird demnach vorgeschlagen, dafi ein Praprozessormittel mit 
einem Codeeingang fur die Einspeisung von zu compilierendem 
Code, mit Codeanalysemitteln, insbesondere Codestruktur 
und/oder Datenformat- und/oder Datenstroms-Erkennungs- 
\md/oder Bewertungsmitteln sowie mit einem Auf teilungsbewer- 
tungsmittel zur Bewertung einer im Ansprechen auf Signale aus 
dera Codeanalysemittel vorgenommenen Codeauf teilung isowie gege- 
benenfalls einem Iterationsmittel zur Wiederholung einer Code- 
aufteilung bis zum Erreichen stabiler und/oder hinreichend ak- 
zeptabler Werte mit zumindest. zwei Teilcodeausg&ngen versehen 
ist, wobei ein erster Teilcodeausgang Teilcode fiir zumindest 
einen herk&mmlichen Prozessor ausgibt, und wenigstens ein wei- 
terer Teilcodeausgang zur Abarbeitung mit rekonfigurierbaren 
Logikeinheiten, insbesondere mehr- bzw. multidimensionale ins- 
besondere Zellstriikturen aufweisend, insbesondere grobgranula- 
re datenverarbeitende und/oder Logikzellen (PAEs) mit Rechen- 
werken xind dergleichen sowie ggf . zugeordneten Registermitteln 
und/oder feingranularen Steuer- und/oder Kontrollmitteln wie 
Zustandsmaschinen, RDY/ACK-Trigger- tmd Kommunikationsleitun- 
gen usw bestimmten Code ausgibt. Beide Teilcodeausg&nge k&nnen 
in multiplexweise seriell auf einem physikalischen Ausgang 
liegen. 

Die Oatenbank fdr die Interface -Codes (0210) wird unabhSngig 
imd vor dem Compilerdurchlauf aufgebaut. Beispielsweise sind 
folgende Quellen fur die Datenbank moglich: Vom Lieferanten 
vorgegeben (0220), vom Benutzer programmiert (0221) Oder auto- 
matisch von einem Entwicklungssystem generiert (0222) . 

Der Aufbau einer besonders bevorzugten VPU ist in Figur 3 dar- 
gestellt. Vorzugsweise hierarchische Konf igurationsmanager 
(CT's) (0301) steuem und verwalten eine Anordnung von rekon- 
figurierbaren Elementen (PACs) (0302) ♦ Den CT's ist ein. loka- 
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ler Speicher fur die Konf igurationen zugeordnet (0303) . Der 
Speicher verfugt weiterhin uber ein Interface (0304) zu einem 
globalen Speicher, der die Konf igurationsdaten zur Verfugung 
stellt. Uber ein Interface (0305) sind die Konf igurationsab- 
lauft steuerbar. Ein Interface der rekonf igurierbaren Elemente 
(0302) zur Ablaufsteuerung und Ereignisverwaltung (0306) ist 
vorhanden, ebenso ein Interface zum Datenaustausch (0307) . 

Figur 4 zeigt einen Ausschnitt aus einem beispielhaften CPU 
System, beispielsweise einem DSP des Types C6000 von Texas In- 
struments (0401). Dargestellt sind Programmspeicher (0402), 
Datenspeicher (0403) , beliebige Peripherie (0404) und EMIF 
(0405) . Uber einen Speicherbus (0406) und einem Peripheriebus 
(0407) ist eine VPU als Coprozessor integriert (0408) . Ein 
DMA- Kont roller (EDMA) (0409) kann beliebige DMA- Transfers, 
beispielsweise zwischen Speicher (0403) und VPU (0408) Oder 
Speicher (0403) und Peripherie (0404) durchfflhren. 

Figur 5 zeigt eine abstraktere Systemdef inition. Einer CPU 
(0501) 1st Speicher (0502) zugeordnet auf den diese schreiben- 
den und/oder lesenden Zugriff besitzt. Eine VPU (0503) 1st mit 
dem Speicher gekoppelt. Die VPU ist in einen CT-Teil (0509) 
und die rekonf igurierbaren Elemente zur Datenverarbeitxmg 
(0510) untergliedert . 

Zur Steigerung der Speicherzugrif f e kann der Speicher mehrere 
unabhdngige Zugrif fsbusse aufweisen (multiport) . In einer be- 
sonders bevorzugten Ausgestaltung ist der Speicher in mehrere 
vinabhangige Segmente (Speicherbanks) segmentiert, wobei auf 
jede Bank unabhangig zugriffen werden kann. S§mtliche Segmente 
liegen vorzugsweise innerhalb eines einheitlichen Adressraums. 



42 



wo 02/103532 PCT/EP02/06865 

Vorzugsweise steht ein Segment hauptsachlich fiir die CPU zur 
Verfilgung (0504)/ ein weiteres Segment steht hauptsSchlich fur 
die Datenverarbeitung der VPU zur Verfugung (0505) , ein weite- 
res Segment steht hauptsachlich fiir die Konf igurationsdaten 
der VPU zur Verfilgung (0506) . 

Typischeirweise und bevorzugt weist eine vollausgestaltete VPU 
eigene Adressgeneratoren und/oder DMAs auf um Datentransfers 
durchzuf ahren . Alternativ und/oder zusStzlich ist es moglich, 
dass ein DMA (0507) innerhalb dea Systems (Fig. 5) fur Daten- 
transfers mit der VPU vorgesehen ist. 

Das System enthait 10 (0508) auf die CPU und VPU Zugriff haben 
k5nnen. 

Sowohl CPU als auch VPU konnen jeweils dedizierte Speicherbe- 
reiche und lO-Bereiche aufweis.en^ auf die der jeweils andere 
keinen Zugriff hat. 

Bin Datensatz (0511) der im Speicherbereich und/oder im 10- 
Bereich und/oder partiell in einem;von beiden liegen kann wird 
zur Kommunikation zwischen CPU und VPU verwendet, z.B. zum 
Austausch von Basisparametem \md St euer information. Der Da- 
tensatz kann beispielsweise folgende Information beeinhalten: 

1. Basisadresse (n) des CT-Speicherbereiches in 0506 zur Lo- 
kalisierung der Konf igurationen, 

2. Basisadresse (n) von Datentransfers mit 0505. 

3. 10 Adressen von Datentransfers rait 0508. 

4. Synchronisationsinformation, z.B. Zuriicksetzen/ anhalten, 
starten der VPU. 

5. Statusinformation der VPU, z.B. Fehler oder Zustand der 
Datenverarbeitung. 
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Die Synchronisation der CPU und VPU erfolgt durch Polling von 
Daten und/oder bevorzugt durch Interruptsteuerung (0512) . 



Figur 6 zeigt eine mogliche Ausgestaltung der Interf acestruk- 
tur einer VPU zur Einbindung in ein System Shnlich Figur 5. 
Dazu warden der VPU ein Speicher/DMA- und/oder 10- Interface 
zum Datentransfer zugeordnet (0601) , ein weiteres System- 
Interface (0602) Obemimmt die Ablaufsteuerxmg wie z.B. das 
Verwalten von Interrupts, das Starten/Stoppen der Verarbei- 
tung, Austausch von FehlerzustSnden, etc. . 

Das Speicher/DMA- und/oder 10- Interface wird an einen Spei- 
cherbus und/oder lO-Bus angeschlossen. 

Das System- Interface wird vorzugsweise an einen lO-Bus ange- 
schlossen, kann jedoch altemativ oder zusStzlich entsprechend 
0511 auch an einen Speicher aiigeschlossen sein. 

Die Interfaces (0601, 0402) kdnnen zur Anpassung von unter- 
schiedlichen Arbeitsfrequenzen von CPU \ind/oder VPU und/oder 
System ausgestaltet sein, beispielsweise kann das System bzw. 
die CPU mit zB derzeit 500MHz und die VPU mit 200MHz arbeiten. 

Die Interfaces kSnnen eine. Ubersetzung der Busprotokolle 
durchfuhren, beispielsweise kann das VPU interne .Protokoll auf 
ein extemes AMBA-Busprotokoll umgesetzt werden. Sie bewirken 
also BusprotokollCibersetzungsmittel und/oder sind fur die Bus- 
protokolliibersetzung ausgebildet, insbesondere die Busproto- 
kollubersetzung zwischen intemem VPU-Protokoll und bekanntem 
Busprotokoll . Es ist auch moglich, eine Konvertierung direkt 
auf CPU- interne Busprotokolle vorzusehen. 

Das Speicher/DMA- und/oder lO-Interface unterstutzt den Spei- 

cherzugriff der CT auf einen extemen Speicher, der vorzugs- 
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weise direkt (memory mapped) erfolgt. Der Datentransfer der 
CT(s) und/oder PAC(s) kann gepuffert z.B. Ciber FIFO-Stufen er- 
folgen. Extemer Speicher kann direkt angesprochen und adres- 
siert werden, weiterhin kdnnen DMA interne und/oder exteme 
DMA-Transfers durchgefiihrt werden. 

t5ber das System- Interface erfolgt die Steuerung der Datenver- 
arbeitung, wie beispielsweise die Initialisiening und/oder der 
Start von Konf igurationen. Des weiteren werden Status und/oder 
Fehlerzustande ausgetauscht . Interrupts fiir die Steuerung und 
Synchronisation zwischen den CT's und einer CPU kSnnen imter- 
stfitzt werden. 

Das System- Interface kann VPU- interne Protokolle derart kon- 
vertieren, dass diese auf exteme (Standard) -Protokolle umge- 
setzt werden (z.B. AMBA) . 

Eiii bevorzugtes Verfahren zur Codegenerierung fair das be- 
schriebene System ist in anderen Teilen dieser Anmeldung be- 
schrieben. Das Verfahren beschreibt einen Compiler, der Pro- 
grammcode in Code fiir eine CPU und Code fur eine VPU zerteilt, 
Nach \mterschiedlichen Verfahren wird die Zerlegung auf die 
unterschiedlichen Prozessoren durchgef uhrt . In einer besonders 
bevorzugten Ausfuhrung werden dabei die jeweiligen zerlegten 
Codes urn die Interf ace-Routinen zur Kommunikation zwischen. CPU 
und VPU eirweitert. Die Erweiterung kann automatisch durch den 
Compiler erfolgen. 

Die nachfolgende Tabellen zeigen beispielhafte Kommunikationen 

zwischen einer CPU und einer VPU. Den Spalten sind die jewei- 

lig aktiven Punktionseinheiten zugeordnet: CPU, System -DMA .und 

DMA-Interface (EDMA) bzw. Speicher -Interface (Speicher-l/P) , 

System- Interface (System- I/F, 0602), CT's, sowie die PAC. In 

den Zeilen sind die einzelnen Zyklen in ihrer AusfCLhrungsrei- 

45 



wo 02/103532 PCT/EP02/06865 

henfolge eingetragen. Kl referenziert eine auszufuhrende Kon- 
figuration 1. 



Die erste Tabelle zeigt beispielsweise einen Ablauf bei Ver- 

wendung der System-DMA (EDMA) zum Datentransf er : 
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Es ist zu erwILhnen, dass die Synchronisation zwischen der EDMA 
und der VPU automatisch iiber das Interface 0401 erfolgt, d.h. 
DMA-Tranfers finden nur statt, wenn die VPU dafur bereit ist. 

In einer zweiten Tabelle ist beispielsweise ein bervorzugter 
optimierter Ablauf dargestellt . Die VPU besitzt selbst direk- 
ten Zugrif f auf den Konf igurationsspeicher (0306) . Desweiteren 
werden die Datentransfers durch DMA-Schaltung innerhalb der 
VPU ausgefiihrt, die beispielsweise fest iraplementiert sein 
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konnen iind/oder durch die Konf iguration von konf igurierbaren 
Teilen der PAC entstehen. 
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Der Aufwand fur die CPU ist minimal. 

Zusammenf assend bef aSt sich die vorliegende Erf indung mit Ver- 
fahren, die eine fjbersetzung einer klassischen Hochsprache wie 
Pascal, C, C++, Java, etc. auf eine rekonf igurierbare Archi- 
tektur ermdgjicht. Das Verfahren ist derart ausgelegt, daS nur 
die jeweils fiir die rekonf igurierbare Zielarchitektur geeigne- 
ten Teile des zu libersetzenden Programmes extrahiert werden. 
Die verbleibenden Teile des Programmes werden auf eine konven- 
tionelle Prozessorarchitektur ubersetzt. . 

In Figur 7 sind aus Griinden der Qbersichtlichkeit nur die re- 

levanten Komponenten (i.b. der CPU) aufgezeigt sind, wobei ty- 
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pisch eine wesentliche Zahl weiterer Komponenten und Netzwerke 
vorhanden sein wird. 



Eine bevorzugte Implementiening wie beispielsweise in Figur 1 
dargestellt kann unterschiedliche Datentransf ers zwischen ei- 
ne r CPU (0701) und VPU (0702) vorsehen. Die auf der VPU auszu- 
fiUxrenden Konf igurationen werden durch den Instruktionsdekoder 
(0705) der CPU selektiert, der bestimmte fur die VPU bestimmte 
Instruktionen erkennt und die CT (0706) derart ansteuert, dass 
diese die entsprechenden Konf igurationen aus einem der CT zu- 
geordneten Speicher (0707) - der insbesondere mit der CPU ges- 
hared werden Oder derselbe wie der Arbeitsspeicher der CPU 
« sein kann, in das Array aus PAEs (PA, 0108) ISdt. 

Es sind CPU- Register (0703) vorgesehen, um bei einer Register- 
kopplung Daten zu entnehmen, zu verarbeiten und in ein CPU- 
Register zuruckschreiben. b Fflr die Datensynchronisation ist 
ein Statusregister (0704) vorgesehen. Weiter ist ein Cache 
vorgesehen, der dafiir vorgesehren ist, daS wenai Daten ausge- 
tauscht werden sollen, die kurz zuvor von der CPU verarbeitet 
wurden, diese voraussichtlich noch iiti Cache (0709) der CPU 
liegen bzw. sofort anschliessend von der CPU verarbeitet wer- 
den. 

Der exteme Bus ist mit (0710) bezeichnet und es werden dar- 
\iber zB aus einer damit verbundenen Datenquelle (z.B. Spei- 
cher, Peripherie) gelesen, bzw. an den extemen Bus und der 
damit verbundenen Datensenke (z.B. Speicher, Peripherie) ge- 
schrieben. Dieser Bus kann insbesondere derselbe wie der ex- 
teme Bus der CPU sein (0712 & gestrichelt) . 

Ein Protokoll (07ll) zwischen Cache und Bus ist implementiert , 
das far einen korrekten Inhalt des Caches sorgt. Mit (0713) 
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ist ein FPGA (0713) bezeichent, der rait der VPU gekoppelt sein 
kann, um feingranulare Datenverarbeitxing zu ermoglichen 
und/oder ein flexible adaptierbare Interface (0714) (z.B. di- 
verse serielle Schnittstellen (V24, USB, etc.), diverse paral- 
lels Schnittstellen, Festplattenschnittstelleni Ethernet, Te- 
lekommiinikationsschnittstellen (a/b, TO, ISDN, DSL, etc)) zu 
weiteren Baugruppen und/oder dem extemen Bussystem (0712) zu 
ermoglichen. 

Entsprechend Figur 8 bef indet sich Speicherbereich des Be- 
triebssystems eine Tabelle oder verkettete Liste (LINKLIST, 
0801), die auf samtliche VPUCALL-Tabellen (0802) in der Re i- 
henfolge ihrer Erstellung zeigt. 
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PatentansprOche 

1. Verfahren zur ftbersetztxng von Prograinmen auf ein System be- 
stehehd aus wenigstens einem ersten Prozessor und einer re- 
konfigurierbaren Einheit, dadurch gekennzeichnet , dafi die 
Codeteile, die f^r die rekonf igurierbafe Einheit geeignet 
sind, bestimrat urid extrahiert und/oder separiert wird, wo- 
bei verbleibender Code zur Abarbeitimg durch den ersten 
Prozessor bestitmnt wird. 

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet , daS dem 
fur den Prozessor extrahierten Code Interface-Code zugefxigt 
wird, der eine Kommunikation zwischen Prozessor und rekon- 
f igurierbarer Einheit entsprechend des Systemes ermoglicht. 
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3. Verfahren nach einem der vorhergehenden Anspruche, dadurch 
gekennzeichnet, dafi dem fur die rekonf igurierbarer Einheit 
extrahierten Code solcher Interface -Code zugefiigt wird, der 
eine Kommxinikation zwischen Prozessor und rekonf igurierba- 
rer Einheit entsprechend des Systems ermoglicht. 

4. Verfahren nach einem der vorhergehenden Anspruche, dadurch 
gekennzeichnet, daS der zu extrahierende Code aufgrund von 
automatisierten Analysen festgelegt wird. 

5. Verfahren nach einem der vorhergehenden Ansprflche, dadurch 
gekennzeichnet, daS Hinweise im Code zur Feststellung des 
2u extrahierenden Code automat isch ausgewertet werden. 

6. Verfahren nach einem der vorhergehenden AnsprGche, dadurch 
gekennzeichnet, dafi der zu extrahierende Code aufgrund von 
Aufrufen von Unterprogrammen festgestellt wird. 

7. Verfahren nach einem der vorhergehenden Ansprfiche, dadurch 
gekennzeichnet, dalS ein Interface-Code vorgesehen wird, 
der eine Speicherkopplung (Shared-Memory) vorsieht 
und/oder eine Registerkopplung \ind/oder eine Kopplung mit- 
tels' eines- Netzwerkes bewirkt. 

8. Verfahren nach einem der vorhergehenden Anspriiche, dadurch 

gekennzeichnet, dafi der extrahierte Code und/oder mit einer 
gegebenen Extraktion erzielbaren Resultate analysiert wird 
und gegebenenfalls die Extraktion mit neuen verbesserten 
Parametem emeut gestartet wird, 

9. Verfahren nach einem der vorhergehenden Anspriiche, dadurch 
gekennzeichnet, daS dem extrahierten Code Steuer-Code zur 
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Verwaltung und/oder Steuerung vind/oder Komnrunikation der 
Entwicklungssysteme zugefilgt wird. 

10. Verfahren nach einem der vorhergehenden Anspruche, worin 
der erste Prozessor eine konventionelle Prozessorarchitek- 
tur aufweist, insbesondere ein Prozessor mit von - Neumann 
- und/oder Harwardarchitektur, Kontroller, CISC-, RISC-, 
VLIW-, DSP- Prozessor. 

11. Verfahren insbesondere nach einem der vorhergehenden An- 
sprache zur fjbersetzung von Prograramen auf ein System be- 
stehend aus einem Prozessor und einer rekonf igurierbaren 
Einheit, dadurch gekennzeichnet, daS die Codeteile, die fflr 
die rekonfigurierbare Einheit geeignet sind, extrahiert 
werden, der verbleibende Code derart extrahiert wird, daS 
er mittels eines beliebigen gewohnlichen unmodifizierten 
fur den Prozessor geeigneten Conqpilers flbersetzbar ist. 

12. Vorrichttmg zur Datenverarbeitung mit wenigstens einem 
herkdmmlichen Prozessor und wenigstens einer rekonfigu- 
rierbaren Einheit, dadurch gekennzeichnet, dafi ein Mittel 
zum informationsaustausch, insbesondere von Daten- und 
Statusinformation, zwischen herkfiramlichem Prozessor und 
rekonf igurierbarer Einheit aufweist, wobei das Mittel so 
ausgebildet ist, daS ein Daten- und Statusinformation zwi- 
schen denselben wShrend der Abarbeitung eines Oder mehrere 
Programme moglich ist vmd/oder ohne daS insbesondere die 
Datenverarbeitung auf dem rekonf igurierbaren Prozessor 
und/oder dem herkdmmlichen Prozessor signif ikant unterbro- 
chen werden mufi. 
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